Expand Bar is not scaled during DPI change #1528
Conversation
Test Results 483 files ±0 483 suites ±0 8m 27s ⏱️ - 1m 41s For more details on these failures, see this check. Results for commit 661396e. ± Comparison against base commit a26b66a. ♻️ This comment has been updated with latest results. |
ShahzaibIbrahim
force-pushed
the
Master103-ExpandBar
branch
from
2c70881
to
1b48004
Compare
ShahzaibIbrahim
force-pushed
the
Master103-ExpandBar
branch
2 times, most recently
from
24acaa2
to
83e05b9
Compare
HeikoKlare
force-pushed
the
Master103-ExpandBar
branch
from
83e05b9
to
91058da
Compare
bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/ExpandItem.java
Outdated
Show resolved
Hide resolved
| @@ -539,7 +539,8 @@ private static void handleDPIChange(Widget widget, int newZoom, float scalingFac | |||
| if (item.height != 0 || item.width != 0) { | |||
| int newWidth = Math.round(item.width * scalingFactor); | |||
There was a problem hiding this comment.
When testing this PR I found that this calculation only work with scale mode quarter. When using integer200, the scalingFactor is always 1, such that items are not scaled. It then looks like this:
Using scalingFactor does not seem to be the right thing here. @akoch-yatta do you know how we could fix tihs?
There was a problem hiding this comment.
The scaling was broken even before and this change doesn't bring any regression. From my understanding we only care about int200 scale mode only if we are regressing something, should we try to fix it for int200?
There was a problem hiding this comment.
Yes, that's not a regression of this PR. Still, the rescaling behavior will still be broken after this PR due to the mentioned bug. Currently, int200 is even the more important case, since it's the default value and will be used with the experimental option for monitor-specific rescaling that we have provided. In the long term, the quarter option should of course be the default one, but for now it's not.
So it's fine for me to only address the repositioning in this PR and keep the resizing for later. We should just make sure that we have an issue to track that and address it as a follow-up task.
There was a problem hiding this comment.
I have created a new issue in our backlog for resizing in int200 case, https://github.com/orgs/vi-eclipse/projects/1/views/1?pane=issue&itemId=86212846
Repositioning is correct I think?
ShahzaibIbrahim
force-pushed
the
Master103-ExpandBar
branch
2 times, most recently
from
f4c102c
to
d27e04e
Compare
When using the monitor-specific rescaling functionality on Windows, moving a shell between monitors with different zoom levels (no matter which zoom levels they are), the images, expand items and texts are not drawn at correct coordinates. This change fixes the behavior to perform an appropriate layout update of the ExpandBar.
HeikoKlare
force-pushed
the
Master103-ExpandBar
branch
from
d27e04e
to
661396e
Compare
When moving from one zoom level monitor to another zoom level (no matter what %), The expanded items and texts are not drawn at correct coordinates.
HOW TO TEST
ControlExamplewith the following VM ArgumentsSCREENSHOTS
Before Fix:
After Fix:
Requires
Contributes to #62 and #127